1. Field of the Invention
The present invention relates to schemes, apparatuses, and programs for header compression and, more specifically, to schemes for compressing packet headers at the transmission end during data transmission on a packet basis, apparatuses with the schemes adopted, and programs for realizing the schemes.
2. Description of the Background Art
Typical protocols for data transmission over the Internet currently include TCP (Transmission Control Protocol)/IP (Internet Protocol), RTP (Realtime Transport Protocol)/UDP (User Datagram protocol)/IP, and the like. At the time of data transmission under these protocols over transmission paths with a low-to-medium bit rate, a data packet will have an RTP header, a UDP header, or/and an IP header, and resultantly becomes large as shown in FIG. 8. Accordingly, the large header may increase communications overhead. As one example, in a case of transmitting 10-byte data under the UDP/IP protocol, its header will be 28 bytes and thus the data size in total will be 38 bytes. The data size becomes almost four times larger than the data which is to be actually transmitted. As a result, the transmission path will be considerably decreased in effective data transmission speed.
In order to reduce overhead increased due to transmission headers, there is a header compression scheme based on “Robust Header Compression (ROHC)” (draft-ietf-rohc-rtp-00. txt Jun. 29, 2000), which is under deliberation by IETF (Internet Engineering Task Force). This header compression scheme is specifically developed for a wireless communications network as shown in FIG. 9 which is mainly for wireless mobile phones. Such a communications network is typified by a mobile telephone network (e.g., W-CDMA) which is now increasingly popular, and specifically used for a section of wireless transmission in FIG. 9.
With the header compression scheme based on ROHC, the transmission end (header compression end) and the reception end (header decompression end) share the same reference information for header compression and decompression. One example of the reference information is timestamp calculation information. This scheme aims to achieve header decompression in a correct manner at the reception end. Referring to FIG. 10, reference information α is used to compress a packet header H1 at the transmission end, and the resultant compressed packet header H′1 is transmitted to the reception end. In response, the reception end uses the same reference information α to decompress the compressed header H′1 to the header H1.
At the time of header compression applied at the transmission end to the header H1 based on the reference information α, the resultant compressed packet header H′1 which is to be transmitted to the reception end is represented as below.H′1=H 1*α  (1)
Here, the symbol * represents any specific computing technique which varies depending on which region is to be compressed. For example, UDP port number→remain invariant, RTP sequence number→generally increase by one, and RTP timestamp→increase by 50. The reference information α includes information needed to compress each of those regions. When such reference information α is correctly retained at the reception end, the original header H1 can be correctly decompressed thereat.
Described now is the scheme for changing the reference information α into reference information β at both of the transmission and reception ends with reference to FIGS. 11 and 12.
When the reference information α is changed into the reference information β, the transmission end compresses a packet header H3 based on the reference information β, and the resultant compressed packet header H′3 is transmitted to the reception end together with the reference information β (see FIG. 11). At this time, presuming that the reference information β is to be correctly updated at the reception end, the transmission end sequentially transmits packets subjected to header compression based on the reference information β without receiving an acknowledge packet ACK from the reception end. Here, the acknowledge packet ACK is the one indicating that the reference information is correctly updated at the reception end. If failing to decompress the original packet header H3 because the reference information β was not correctly updated due to transmission error, for example, the reception end transmits a NACK packet to the transmission end so as to request it for transmitting the reference information β again (see FIG. 12).
FIGS. 13A to 13C show formats of various packets which are used as headers.
An initialization packet header (FIG. 13A) carries information which remain always the same throughout packet transmission (e.g., IP address, UDP port number), and the information is transmitted on a 4-byte basis. Transmitting once is enough for this type of information included in this packet.
A reference information update packet header (FIG. 13B) carries reference information, and the like, and such information is transmitted on a 3-byte basis. The reference information update packet header includes a Y bit and an RTP-TS, which are, respectively, a marker bit and a timestamp added by RTP. With a Z bit in the packet set to “1”, any other type of reference information can be also transmitted thereby. FIG. 14 shows the format of an extension portion which is added to the reference information update packet header when the Z bit is set to “1”. Therein, a T bit indicates whether or not there is a delta timestamp field, denoting a timestamp increase per sequence number. An S bit indicates whether or not there is a “Type Of Service” field in an IP header, while an L bit indicates whether or not there is a “Time To Live” field in the IP header. A P bit indicates whether or not there is a “Payload Type” field in an RTP header. By setting the Z bit and any other necessary bits (e.g., T, S, L, P), the corresponding information (minimum; 2 bytes, maximum; 5 bytes) can be added to headers.
In a minimum compression packet header (FIG. 13C), a sequence number and a CRC check sum are transmitted by 1 byte. This sequence number and the reference information transmitted by the reference information update packet header are used to decompress the original to-be-compressed packet. The CRC is used to check whether packet decompression has correctly worked out or not.
Described below are schemes for using and updating any specific reference information for compressing a timestamp, which is a part of header information. For compression/decompression of timestamps, the transmission and reception ends share the same reference information. Herein, the reference information is specifically timestamp calculation information dTS (e.g., delta timestamp ΔTS).
For header compression at the transmission end applied to a timestamp T(SN) with a sequence number SN based on the timestamp calculation information dTS, decompression applied to the timestamp at the reception end is performed in accordance with the following equation (2).T(SN)=dTS×x+T(SN−x)  (2)
Here, “SN−x” (where x is a positive integer) denotes the sequence number of a packet which is received most recently, and “T(SN−x)” denotes its timestamp.
Thanks to the equation (2), the compressed packet header has no more need to carry a timestamp. If the reception end retains the timestamp calculation information dTS, the RTP sequence number will be enough for timestamp decompression. That is, the transmission end can delete (=compress) the timestamp from the header.
The timestamp calculation information dTS which is updated at the transmission end is forwarded to the reception end by the reference information update packet header (FIG. 13B). To be specific, in the reference information update packet header, the Z bit has been set, and the timestamp calculation information dTS has been updated and stored in the delta timestamp field of the extension portion (FIG. 14). In the case that the transmission and reception ends retain the same timestamp calculation information dTS, transmitting only the sequence number by the minimum compression packet header (FIG. 13C) can decompress the timestamp.
It should be noted that, for timestamp decompression at the reception end, the equation (2) works out only when the transmission end performs header compression in accordance with the timestamp calculation information dTS retained at the reception end. Therefore, in the case that dt(SN)=(T(SN)−T(SN−x))/x is different from the timestamp calculation information dTS, i.e., if the timestamp calculation information dTS has been updated, the transmission end cannot delete the timestamp from the header. As a result, if this is the case, information is transmitted by the reference information update packet header with the non-compressed timestamp included. Here, transmitted is not the timestamp calculation information dTS, and thus there is no need to set “1” to the Z bit of the reference information update packet header.
FIG. 15 shows an exemplary structure of a header compression apparatus (transmission end) for carrying out the conventional header compression scheme. As shown in FIG. 15, the conventional header compression apparatus includes a timestamp calculation information computing part 101, a timestamp compression scheme determination part 103, a timestamp calculation information tracking part 104, a timestamp non-compression part 105, a timestamp compression part 106, and an input switch part 108.
The operation of each of these constituents of the above conventional header compression apparatus is described below.
The timestamp calculation information computing part 101 sequentially receives packets together with their headers which are to be compressed. The timestamp calculation information computing part 101 then computes the timestamp calculation information. Specifically, computed are a difference in terms of timestamp between the current packet i (where i is a positive integer) and another packet (i−1) one before the packet i, and a difference therebetween in terms of sequence number. In this manner, obtained is a delta timestamp Δt(i) which denotes a timestamp increase per sequence number.
The timestamp calculation information tracking part 104 keeps track of timestamp calculation information, i.e., delta timestamp ΔTS, which is predetermined for timestamp compression.
The timestamp compression scheme determination part 103 compares the delta timestamp Δt(i) obtained by the timestamp calculation information computing part 101 with the delta timestamp ΔTS which is kept track by the timestamp calculation information tracking part 104. If both delta timestamps are found as being the same, i.e., Δt(i)=ΔTS, the timestamp compression scheme determination part 103 determines that the timestamp should be compressed. Thus, the input switch part 108 is so controlled that the packet i is forwarded to the timestamp compression part 106. On the other hand, if those delta timestamps are found as being not the same, i.e., Δt(i)≠ΔTS, the timestamp compression scheme determination part 103 determines that the timestamp should not be compressed. Accordingly, the input switch part 108 is so controlled that the packet i is forwarded to the timestamp non-compression part 105.
The timestamp non-compression part 105 deletes the timestamp before performing packet header compression in accordance with the format of the reference information update packet header of FIG. 13B.
On the other hand, the timestamp compression part 106 does not delete the timestamp before performing packet header compression. That is, in accordance with the format of the minimum compression packet header shown in FIG. 13C, the timestamp is deleted (=compressed) so that the resultant packet header includes only the sequence number.
The input switch part 108 outputs the incoming packet i, under the control of the timestamp compression scheme determination part 103, to either the timestamp non-compression part 105 or the timestamp compression part 106.
By referring to the flowchart of FIG. 16, the entire procedure of the header compression scheme carried out by such a conventional header compression apparatus is described.
First, the delta timestamp ΔTS is registered (updated) (step S161). Its value may be predetermined, or a value obtained by computation between first and second packets may be used. Once an arbitrary packet i has been inputted, the delta timestamp Δt(i) will be computed (step S162). Then, the delta timestamp Δt(i) and the delta timestamp ΔTS are compared with each other (step S163). Here, if these delta timestamps are found as being the same, the minimum compression packet header carrying no timestamp is generated (step S164). If not the same, the reference information update packet header carrying a timestamp is generated (step S165). Then, if there is any packet left for such a sequence of processes (steps S166, S167), the procedure returns to step S162 and repeats the same sequence.
In the above conventional header compression scheme, however, if there observed any value change in timestamp, the timestamp is not compressed before packet transmission. The issue here is, if the timestamp remains the same for sometime after the value change, the timestamp has to be transmitted without compressed for the duration, resulting in poor efficiency in header compression.
This problem is described specifically with reference to FIG. 17. In the exemplary diagram shown in FIG. 17, the left column is for packet headers inputted at the transmission end, and indicates their sequence numbers and timestamps. The right column is for packet headers which are those obtained by applying the conventional header compression scheme to the input packet headers and outputted from the transmission end, and indicates their delta timestamps, header formats, and the numbers of bytes. In FIG. 17, MIN denotes the minimum compression packet header (FIG. 13C), while REF denotes the reference information update packet header (FIG. 13B) in which the Z bit is not set to “1” and thus no extension portion is added. Herein, the delta timestamp is presumably set to “10” in advance.
In the example of FIG. 17 under the conventional header compression scheme, the delta timestamp remains the same, i.e., “10”, from the sequence numbers 10 to 13. Accordingly, only the sequence number is transmitted by the minimum compression packet header which is a 1-byte header, i.e., MIN. As to the sequence numbers 14 to 18, their actual delta timestamps are not “10” but “20”. Therefore, both of the sequence number and the timestamp are transmitted by the reference information update packet header which is a 3-byte header, i.e., REF. Further, as to the sequence numbers 19 and 20, their delta timestamps are again “10”. Accordingly, transmitted is only the sequence number again by the 1-byte header MIN.
As such, the conventional header compression scheme results in poor efficiency in header compression with varying delta timestamps.
Here, if it is known in advance that the sequence numbers 14 to 18 carry the same delta timestamp as “20”, such header compression as shown in FIG. 18 is possible. By taking the packet of sequence number 14 as an example, the REF of 3 bytes and its extension portion (EXT) of 2 bytes are used to transmit the delta timestamp “20” so that the delta timestamp at the reception end is changed. As a result, the packets of sequence numbers 15 to 18 can be transmitted by the MIN of 1-byte. As to the packet of sequence number 19, the delta timestamp at the reception end is changed back to “10” by the REF+EXT of 5 bytes in total.
Accordingly, with such a process, the number of bytes needed to transmit packet headers of sequence numbers 10 to 20 is reduced to be 19 bytes compared with 21 bytes under the scheme of FIG. 17. With this scheme, however, the efficiency in header compression remains still poor because the number of bytes needed for header transmission is increased if the timestamp does not remain the same for sometime after its value change.